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Amendments to Claims as ner tbis response. 

5 No amendments. 



ftir nmarv of differences between Rosen a nd our invention. 

10 



Subject 


Rosen 


Our Invention 


Comments 


Structure 


Use Modules such as Transaction 
4. Teller 5 and Money Generator 6 
which are embedded or interfaced 
with a device such as a PC. A tank 
network 25 and subnetwork; 
16,17,18- ( See Fig 2 and 7) 

Rosen actually f might against 
using prepaid sxnartcards See Col 2 
line 17 to 24 wherein chip based or 

TrtngneJir! hnttui Ohvimisty in view 

of technology, Rosen made no 
mention of non-technological 
cards such as found in our 
invention. There is no evidence to 
show non-technological cards. 


A plastic/paper card 
with a security code 
hidden under a scratch- 
off. 

A host server. 

A roerctem* server^ The 
merchant server is 
engaged in a payment 
transaction by sending 
verification codes to 
host and payer) 

A payer linking by a 
network to host and 
nierchant. 


Could the sophisticated 
module found in Fig 
4 t 5,6 could inherent 
show a plastic/paper 
card? 

Our host server is not a 
banking system and 
Rosen actually taught 
his modules for user to 
user to work without 
the banking network. 

Our host server only 
contains untraceable 
codes, account 
identifiers, passwords 
preserving anonymity. 
There is no deposit 
accounts. 

In contrast, each 
modules are embedded 
with traceable codes 
known as electronic 
notes 11 and fixed 
identifiers. 


Network 


Each Modules are linked with each 
other for the purposes of making 
payment/withdi awal/FX to other 
Transaction 4 , Teller 5 (Bank) 
and Money Generator 6 within the 
network. 


Merchant server link to 
Host server and payer 
for payment to merchant 
Only. 

For payer to payee 
requires host server and 
payer only. We do not 
have payer interacting 
with payee in the 
payment process as 


Rosen assumes the 
merchant is a POS with 
the embedded 
transaction module 4. 
Hence all payment is by 
way of module to 
module through network 
16,17,18 or 25 where 
both payer and payee 
need to sign on to 
establish sessions. This 
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found in Rosen 
particularly for sign on 
process. 


means without 
mtermediary. 


Account 
Identifiers 


These are fixed by issuer (bank) of 
device or modules and linked back 
to deposit accounts or credit notes. 
( Col 12, lines 2!KJ3) 


The users choose their 
own identifiers hence 
preserving anonymity as 
per real money. ( Claim 
3 now cancelled ) 


Could one skilled in the 
art reading identifiers 
fixed by Issuer 
inherently see user 
choosing their own 
laeunners < 


Electronic 
Money -Notes 
11 . 


Us er need a deposit account or 
credit facility with a bank to draw 
electronic notes 11 generated by 
teller 5 coupled with money 
generator 6 to transaction module 
4. Electronic notes are embedded 
with traceable identifiers signed by 
each payer or bank to user's 
deposit account. ( Col 1 7, line 4 to 
line 19) 


User to buy a prepaid 
card with amount 
already linked to 
security code in 
database. Upon linking 
to account identifier and 
password, the amount is 
calculated as stored 
value in database and 
security code is useless. 
Since account identifier 
is created by user it is 
artotrymous. 


Account identifier is to 
provide simple way to 
link to stored vahie in 
lieu of the security code 
on prepaid card which is 
made valueless upon 
converting to stored 
value. Card can be 
discarded. There is no 
digital certificate or 
traceable tokens 
gmogooeo mine 
'money* as our funds 
are recorded in a single 
database and do not 
travel from module to 
module. 


Payment 
Protocol 


Payor to establish connection by 
iderujiying the local network 
16, 17,18 destination and this will 
route to the appropriate money 
module for establishing a session ( 
Col IS, line 11 to 19) 


Given our method is 
centralised at the host 
server, the payor need 
only provide payor's 
identifier, password and 
payee's identifier and 
amount to effect the 
transfer. No interacting 
with payee. 


There is no 

cornmunication between 
modules as we do not 
use modules. Therefore 
how could one skilled in 
the art inherently see a 
cexitraUsed method at 
host server from one 
that teach away from 
using centralised 
method by applying 
modules to modules ? 


Authentication 
of electronic 
money 


Check the digital signature of 
money generator and past payons. 
"Money" is moved from module to 
module (Col 11 line 66 to Col 12 
line 6) 


"money* does not 
travel/transmit from 
module to module as we 
do not have modules to 
effect the transfer. Our 
funds or money remains 
io a central database and 
we merely credit payee 
and debit payer's 
account to reflect the 
transaction. Therefore 
there is no requirement 
for authentication of 


"money" stays in 
database being a credit 
and debit entry, hence 
there is no 

authentication of money. 
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money. 




Intermediary 


Rosen taught against the use of an 
intermediary such as a banking 
system Col 2, lines 42-45. Also see 
Col 2, tine 34-41. As mentioned, 
Rosen use modules to modules to 
do this. 


White we do not use 
bank system, we use the 
prepaid service provider 
system in the form of a 
host server to eJEJec* 
transaction 


The question here is 
whether the teaching 
against intermediary 
would inherentry show 
using a non banking 
intermediary snch asa 
service provider in view 
of teaching including 
against the use of 
prepaid card mstmments 
? 



















5 Our Response to the examinees rejection as per each claim . 



As per Claim 13.17.22 

10 This is a 102(b) rejection. 

This rejection is respectfully traversed. We have grouped all claims 13,17, 22 as they 
have the same elements except for different classes where Claim 13 is the representative. 

15 The examiner stated evidence from Rosen: Abstract, Background/Summary of the 
Invention; Fig 3 -10, associated text and Fig 34-36c, 36-36a, 46-46a) We believe the 
examiner mean 34c ( Fig 3 4-3 6c) as 36c does not exist. 

Fig 3-10 refers to Rosen's modules and network embodiments which as we submitted is 
20 not found in our invention. No modules are used here as we only apply a command at 
host server to credit and debit payee and payor respectively. As mentioned, Rosen teach 
against using an intennedjary ( Col 1 line 36 ) 

Fig 34-34c. 36-36a, 46-46a refer to withdrawal, user to user transfer of funds/FX and 
25 protocols. We submit these are not relevant simply because we use a prepaid card for the 
funds initially and thereupon stored in database and there is no modules in our invention. 
And obviously a module could not show a database as found in our host server with 
numerous account identifiers and passwords etc. Similarly the module in Rosen could not 
inherently show a paper/plastic card. Without able to link a programmable suite such as a 
30 module to one of our element, prima facie there is no anticipation since it is the module in 
Rosen that is being used for all the transactions. Secondly, a module need to link up with 
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another module for < Fig 36 ) transaction as in Rosen but since there is no module in our 
invention, there is no link up resulting in no interacting with payee. 

Rosen disclosed an invention using a money module to make transfer between money 
5 modules in lieu of bank accounts. This is evident from Col 2 Ln 42- 49 which is cited by 
the examiner and reproduced below for clarity : 

" Thus there is a need for a system that allows common payer to payee economic 
exchanges without the intermediation of the banking system, and that gives control of the 
10 payment process to the individual. Furthermore, a need exists for providing a system of 
economic exchange that can be used by large organizations for commercial payments of 
any size, that does not have the limitations of the current EFT systems. ** 

Further from Col 8 Ln 52-62 which is cited by the examiner and reproduced below for 
15 clarity : 

" It should be noted that a subscriber will not be required to maintain a bank account in 
order to own and use a Transaction money module 4. For instance, a subscriber may 
obtain a stand-alone computing device that contains a Transaction money module 4 and 
20 use the device only in off-line peer to peer transactions with other services containing a 
Transaction money module 4, such as a merchant's point of sale terminal. Of course, the 
merchant may then transfer the electronic money to another commercial organization to 
meet its obligations, or it may deposit the electronic money at its own bank. " 

25 

Summary 

Our claim 13 at pre-amble reveals firstly: money stored in a database at a server and not 
in any module or stand-alone computing device as found in Rosen. As mentioned Rosen 

30 was actually critical of system that ignore deposit money in the bank as a way to back up 
the economic representation outside of the banking system and the use of prepaid cards ( 
Col 2, lines 17-24 ). Claim 13 actually requires the money to be represented in a database 
not found in Rosen unless the module could be said to be a database and even if this is 
inherent, logically such modules could not possible stores other user's linked funds as 

35 found in our claim. There is nothing in Rosen which taught of using a host server to 
effect the transfer. Apparently the examiner provided evidence that explicitly show 
execution between modules and not with a host server. Structurally, our database stores 
all the users details while each module in Rosen is linked to an individual user which are 
incompatible. In feet Rosen taught of not using a host server as found in CoJ 1 line 36. 

40 Further the evidence shows module to module with payor and payee interacting as in Fig 
36. Even if there is a connection to a main intermediary system, this is not for transfer of 
funds between user to user as found in this claim. The said system is merely to facilitate 
download and upload for clearing the E-notes 1 1 between user and bank. It is also not 
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well known to transfer under payer's control as known in Rosen nor in ACH or EFT 
being relied by the examiner to show fully automated. 

5 Modules in Rosen to show our plastic/paper prepaid card or host server or merchant 
server? 

Even if prepaid card is not explicitly claimed in Claim 13, the word " stored funds " 
10 would inherently show that such funds are calculated and stored from a prepaid card as 
read in our specification. Applicant submits that Rosen* s modules which is the novelty of 
his invention is not found at all in our invention. The examiner provided no evidence to 
show this critical application which serves to operate payment, FX and transfer inherently 
shows our non-module transactions. Could a module of capable of such complex 
15 applications ( See Fig 4,5,6) be inherently in a plastic or paper card ? Or alternatively in a 
host server with a database with identifiers, stored funds and passwords ? Rosen however 
only teach the transfer is done from module to module and not as in our invention at a 
host server by payor without interacting with payee. The examiner provided no evidence 
to support any of the assertions and it is obvious that a paper/plastic card could not 
20 transmit funds to each other. And while ACH or RFT could be relied, these fully 
automated exchange process does not inherently shows under payor's control. 

Source of funds from Deposit Account jre^PT M™ n from a prepaid card. 

25 

We submit Rosen's invention is limited by the fact that the source of the funds which are 
stored in these modules originates from a bank deposit account or credit line, in short one 
must have the deposit account or credit line with a bank before able to use the 
downloaded electronic funds in the modules. The evidence for this is explicitly found in 

30 Col 2 In 24-28 which alluded the need to use bank deposits as money to be backed up in 
electronic form. In fact Rosen was critical of systems that do not have this feature of 
using money derived from a bank deposit account Obvious, after the electronic money 
with the bank signature has been downloaded to a module, said can be used without 
maintaining the bank depositing facility is clear but this does not mean there is no bank 

35 account for this purpose at the outset. 

Since Rosen's module is designed to be used outside of the banking system hence deposit 
account is made redundant is obvious but it is clear that a banking facility must be used at 
the outset, particularly when the originating bank's digital signature is needed to create 
40 the electronic money. Also note that the last sentience refers the merchant to a bank for 
depositing which again highlights the need for a deposit account. Therefore, the evidence 
provided by the examiner Col 8 Ln 52-62 represents partial inaccuracy as they were taken 
out of context and could not suggest that Rosen* s invention could work without any 
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banking-deposit facilities at all. This is clearly in contrast to our claim where the money 
is represented in a prepaid card and to be activated by associating with a user identifier 
that h could be stored in the database for transactional purposes. The database serves as a 
central book-keeper (intermediary) enabling as many users as possible to make transfer 
without interacting with payee as this is an one way transaction. There is no deposit 
account at all in our invention. As mentioned, Rosen even taught against the use of an 
intermediary such as a banking system ( Col 2, line 42-45). As our claim here is for user 
to user using funds stored from prepaid card and not deposit , this would not inherently 
show our element 

Under Paver's Control as found in our pre-ambl e is contrary to automating payee's steps 
as suggested by examiner. 



Further, Claim 13 requires the payment transaction to be at payer's control. It is quite 
35 clear in Rosen that his module requires the interaction between payer and payee, 

including Payee's acceptance at steps 832 & 836 in FIG 36A. TTiese are not trivial steps 
to be dismissed by suggesting automation is taught by Rosen. 

Even if this is automated at payee's module, how would the payer be in control when the 
20 payee's module is running in automation mode as suggested by the examiner. Can the 
payer control this automation found in the payee's module ? 

The examiner provided evidence from Abstract, Background/Sununary. The best 
illustration can be seen by the method of making transfer in FIG 36 & 36A in particular 
25 showing step 810 where A choose to pay and step 812 where B choose to receive. The 
tact that B is involved throughout the whole process would show that it is not exclusively 
under payer's control or without interacting with B. 



This is evidenced by Rosen at Col 49 Ln 12 onwards and reproduced below for clarity : 



"Both Alice and Bob sign on to their respective Transaction money modules 4 using the 
process Steps 10-42 described above. Through the To Subscriber A 33 application, Alice 
directs her Transaction money module 4 to make a payment (Steps 806 & 810), while 
Bob operates his Transaction money module 4 such that the To Subscriber B 33 
35 application will issue an entitlement to receive payment (Steps 808 & 812). ** 

The examiner asserted that Rosen clearly teaches that his system may be fully automated 
and provided evidence from Col 4 Line 49-52 to support inherency. For the sake of 
clarity we have produced the entire section Col 4 Line 32 to 67 below in order to cover 
40 every possible suggestions: ( Underlined means where the examiner's evidence are 
shown L 49-52 ) 
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" In accordance with these and other objects of the invention, a brief summary of the 
present invention is presented. Some simplifications and omissions may be made in the 
following summary, which is intended to highlight and introduce some aspects of the 
present invention, but not to limit its scope. Detailed descriptions of a preferred 
5 exemplary embodiment adequate to allow those of ordinary skill in the art to make and 
use the inventive concepts will follow in later sections. 

According to a broad aspect of the invention, an electronic monetary system provides for 
transactions utilizing electronic money including electronic currency backed by demand 

10 deposits in a bank in lieu of cash transactions, and electronic credit authorizations. The 
invention comprises a money module for generating the electronic m onev: a money 
module for issuing, distributing, and accepting the electronic monev: and a money 
module for accepting, storing, and transferring the electronic money between other 
accepting money modules and between the accepting money mod uje and the issuing 

15 monev m odule. 

According to a further aspect of the invention, an electronic monetary system is provided 
for implementing and maintaining electronic money which includes electronic currency 
that is interchangeable with conventional money through claims on deposits in a bank and 
20 electronic credit authorizations. 

The system includes a plurality of issuing banks; a generator module for creating 
electronic money; teller modules coupled to the generator module, for performing teller 
transactions and for interfacing with other teller modules, such transactions including the 

25 accepting and the distributing of the electronic money; a security system for providing the 
overall integrity of the electronic monetary system; a clearing and settling process for 
balancing the electronic money accounts of the separate issuing banks and for clearing 
the electronic money issued by the issuing banks; and a plurality of transaction modules 
owned by authorized users, for transferring the electronic money between the transaction 

30 modules and between the transaction modules and the teller modules. ** 



Did Rosen actually teach automation to reveal non interacting wi th payee as suggested by 
the eyg^ner 7 

35 

The reference to automation is one used to show the desirability to utilize economic 
exchange at a lower cost ( Col 1 , 35 - 40 ) over the use of paper money and coins as the 
means of automating individual transactions between institutions for clearing or 
settlement. Essentially, Rosen is suggesting automation in preference over manual when 
40 paper and coins are used instead. " The extensive use of coins and currency transactions 
has limited the automation of individual transactions such as purchases, feres ." (Col 1, 
line 20-25). 
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In Col 2, line 1-5, Rosen explained his problem for transferring funds between the 
accounts of a merchant and customer within current EFT system and the desirability for 
an automated transaction system that provides fox the transfer of universally accepted 
economic value outside of the banking system not found in EFT- EFT services are a 
5 transfer of payments utilizing electronic checks primarily by large organization ( Col 1 
line 39 - 46) Automation here is referencing the ease of using these electronic "checks" as 
a way to make payment. No teaching of automating payment steps are evidenced. 

In ACH ( Col 1 line 46-54 ), Rosen merely mentioned that such EFT systems requires a 
10 banking system to make payments. Again nothing evidencing automating the steps to 
make payment. Rosen continued in Col 1 line 65 to Col 2 line 5 by adding credit cards, 
debit cards as being part of the EFT system cannot satisfied the need for universally 
accepted economic value outside the banking system. In short, Rosen 13 raising the point 
that a system that is independent from banking must be found. Nothing here actually 
15 teach automating the transfer steps. So far our conclusion is that the word ** automated " 
is merely a reference to a payment system that works like a EFT (ie using electronic 
checks ) but which is independent to a banking network and accepts universal values. 
This is supported by Rosen's remark in Col 2 line 5 to 16) 

20 The word "automated" is further found in Col 2 line 34 " . . . includes not only automated 
devices that allow subscribers to transfer electronic funds or money The word 
automated device clearly shows the meaning as explained ".. allows subscribers to 
transfer electronic funds or money between them without any intermediating system, but 
that also encompasses and include an entire banking system for generating the value 

25 represented by the electronic money and for clearing and settling the electronic money 
accounts of the banks and financial institutions involved to maintain a monetary balance 
within the system. " ( Col 2, line 34-41 ) 

As noted above, there is no actual teaching in regards to automate steps needed to execute 
30 a transfer in a module or how this can be achieved. Rosen's automation is one of devices 
automated to do transfer funds found within context of automation as used in the EFT 
system, ie using some electronic check to automate the process in lieu of cash. It is not a 
direct reference to automating steps needed to transact a fund transfer such as to 
inherently show without interacting with payee as suggested by the examiner. In short it 
35 is doubtful that a reference applying the generality of EFT ("electronic checks") could 
inherently shows automating the crucial steps to effect a transfer of funds. Electronic 
checks are the media for the transfer but they are not the steps needed to make such a 
transfer. 

40 Rosen's teaching for fund transfer shows a money module that requires active 

participation from the payee including signing on whereby the payee is required to 
provide PIN for authentication, to check sum and amount transferred or to agree with the 
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exchange rate. How could these steps which requires judgement inherently suggest that 
Rosen taught automation ? 

5 Hindsight Analysis. 

As mentioned, automation means transaction systems such as found in EFT or ACH 
rather than in modules ( Col 1 Line 39 to 54) which in part relies on value exchanges 

10 achieved through a centralized computer. There is no evidence that Rosen's modules 
could be automated or that Rosen taught automating his modules. The examiner had 
applied the word 'Tully Automated" to mean automating the steps while Rosen's 
teaching of ACH or EFT wherein automation is relied only shows a transaction system 
using electronic checks as the means for automation. We submit the proper application of 

15 inherency as permitted by MPEP 2131.01 under "Extra Reference or Evidence Can Be 
Used To Show an Inherent Characteristic of the Thing Taught by the Primary Reference" 
is not properly applied because the 'thing' in the primary reference is missing. The thing 
being our Without interacting with payee" which is not anticipated and therefore by 
applying the inherent characteristics of EFT to show "automation" is erroneous since we 

20 did not claimed said system. 

In relying upon the theory of inherency, the examiner must provide a basis in fact and/or 
technical reasoning to reasonably support the determination that the allegedly inherent 
characteristic necessarily flows from the teachings of the applied prior ait.** Ex parte 
25 Levy, 17 USPQ2d 1461, 1464 (Bd. Pat. App. & Inter. 1990) (emphasis in original). In this 
respect the examiner provided no reasoning why the modules could be automated ( the 
missing thing assuming by automation it will show without interacting with payee ) 
which must necessarily flow from the teachings of the applied prior art. 

30 Even if ACH and EFT system could be applied by one skilled in the art, there is no 
evidence that such system or Rosen's is capable of showing without interacting with 
payee. The fact that one skilled in the art is capable doing something when there is no 
teaching, does not mean it inherently shows this thing. The teachings particularly in Fig 
36-36A reveal numerous requirement to interact and nothing in Rosen shows automation 

35 must necessary show without interacting with payee. 

Further even if there is teaching of automation, there is also no suggestion that by 
automation, it must necessarily shows without interacting with payee as so further 
suggested by the examiner. Again there is no evidence of this. W.L. Gore & Assocs.. Inc. 
40 v. Garlock Inc., 721 F.2d 1540, 1553, 220 USPQ 303, 312-13 (Fed.Cir. 1983) ("To imbue 
one of ordinary skill in the an with knowledge of the invention in suit, when no prior ait 
reference or references of record convey or suggest that knowledge, is to fall victim to the 
insidious effect of a hindsight syndrome wherein that which only the inventor taught is 
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used against its teacher."). Skill in the art does not act as a bridge over gaps in substantive 
presentation of an obviousness case, but instead supplies the primary guarantee of 
objectivity in the process. £s§ Rvko Mfy. Co. v. Nu-Star. Inc.. 950 F.2d 714, 718, 21 
USPQ2d 1053, 1057 (FedCir. 1991). 

5 

In short the evidence does not feirly teach one skilled in the art to practice ** under the 
control of payer and without interacting with payee ** reading claim 13 as a whole. For a 
prior art reference to anticipate a claim, the reference must disclose each and every 
element of the claim with sufficient clarity to prove its existence in the prior 
10 art . . . Although this disclosure requirement presupposes the knowledge of one skilled in 
the art of the claimed invention, that presumed knowledge does not grant a license to read 
into the prior art reference teachings that are not there. ( Motorola, Inc V Interdigital 
Tech Corp., 121 F.3d 1461, 43 USPQ 2d 1481, 1490 (Fed, Cir 1997)) 

15 Inherency cannot be established bv probabilities or po ssibilities. 

The mere fact that a certain thing (without interacting with payee ) may result from a 
given set of circumstances is not sufficient. (In re Oelrich, 666 F.2d 578,581,212 USPQ 
323,326 (CCPA 1981) (quoting Hansgirg V Kemmer, 102 F.2d 212, 214, 40 USPQ 

20 665,667 (CCPA 1939)) (emphasis added). Thus, inherency permits in limited 

circumstances, to gap minor but well known features or functions as seen by one skilled 
in the art. To show inherency, the missing element must be so well known and recognized 
by one skilled in the art and to rely on inherency to establish the missing features " 
without interacting with payee n , case law in Ex parte Levy, 1 7 USPQ2d 1461 , 1 464 

25 (Bd. Pat. App. & Inter. 1990) requires the examiner to provide a basis in fact and/or 

technical to support this. None was demonstrated and neither did the examiner show how 
this automation is achieved. 

The examiner did not explain how Rosen* s system may be fully automated and as we 
30 mentioned the evidence only show Rosen proposed bis system to cover "a money module 
for penerating the electronic m onev: a money module for issuing, distributing, and 
accepting the electronic m oneyi,an d a money module for accepting, stori ng and 
transferring the electronic monev between other accepting monev modules and between 
the accepting money module and the issuing money module " but fall short of teaching the 
35 automation feature. We respectfully submit that by reading the above 'teaching' one 

skilled in the art may not inherently read automation. The above show desirable features 
bearing the mark of his invention BUT reading with Fig 36 covering extensive teaching 
of interaction, we are doubtful Rosen would now suggest that it could be automated to 
inherently show "without interacting". 

40 

It also appears the examiner had included personal knowledge in arriving at this 
conclusion to connect automation to inherently reveal " without intervention "..As the 
examiner provided no evidence to reveal how Rosen's invention is capable of being 
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Fully- Automated nor provided any reference to support this a Fully Automated must 
necessarily show "without interaction" , we respectfully raise the requirements of 37 CKR 
1 . 104 (d)(2), in part so we can be afforded to the right to rebut. 

5 

All elements must be present for anticipation to stand. 

The examiner did not specifically provide evidence to show each one of the elements 
10 appearing below so we presume they would be covered under the entire Patent as they 
must for a prima facie 102(b) assertion. 

Even if the effect may be similar given a set of circumstances, the fact still shows 
different elements being applied > in Rosen this is done with modules as suggested by the 
is examiner and in our case; payer controlling the process over a network connected to a 
database as shown in our steps in claim's body. Rosen* s modules that do not exist in our 
claim must also acknowledge every steps as arranged herein. 

The standard for anticipation is rigorous requiring that every element of the claimed 
20 invention, as arranged in the claim, be disclosed either specifically or inherently by a 
single prior art reference. See Minnesota Mining & Mfg. Co. v. Johnson & Johnson 
Orthopaedics, Inc., 976 F.2d 1559, 1565 (Fed.Cir.1992); Scripps, 927 F.2d at 1576-77; 
LtndemannMascninenfabrik GMBH, v. American Hoist & Derrick Co., 730F.2d 1452, 
1458 (Fed. Cir. 1984). Every element of the challenged claim need not be expressly 
25 delineated in the single prior art reference, but may be inherently disclosed by prior art if 
"the prior art necessarily functions in accordance with the limitations" of the challenged 
claim. King y 801 F.2d at 1326; see also Standard Havens Prods., Inc. v t Gencor Indus., 
Inc., 953 F.2d 1360, 1369 (Fed. Cir. 1991), cert, denied, 506 US. 817, 113 S.Ct. 60, 121 
LEd.2d28 (1992). 

30 

We Brst look at Fig 36 from Rosen where we will examine them for evidence to 
anticipate our steps. For anticipation to stand, not only each element must be present but 
also the order of the claims steps must be the same. 

35 Our claim 13 is without the benefit of a module and its executable at the host server by 
first prompting the payer for account identifier and password, Rosen's teaching shows 
modules in respective subscriber's devices (See Fig 3) rather than hosted centrally which 
means module to module transfer. In Rosen as in step 10-42 as per Fig 36, Rosen's 
teaching shows interacting with payee module such as B signs on money module. This 

40 parallel step is not found in our claim 13 and it also violates pur element where there is 
no interaction with payee. 
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Our claim also includes prompting payer for payee's identifier which is not found in 
Rosen as presumably this step is replaced by B signing on money module by him/herself, 
a step that could not be read as under payer* s control. As noted in step 190-258 of Pig 36 
in Rosen when both parties are sign-on and only then can transfer session be established. 

5 

This requirement for both payer and payee to sign on is not found in our claim 13 as only 
the payer is sign on for the payment process hence under payer's control. Therefore, even 
if the examiner earlier allegation that automation is found, it still could not anticipate our 
claim as folly automation would still require both modules to sign-on by synchronization 
10 rather than having payer attempting all the process steps found in our claim 13. In short, 
as long as there are two modules as taught in Rosen (regardless whether it is automated or 
not) interacting then this would violate our claim element of not interacting with the 
other. 

15 This is not the same as our claim where the stored fond is already found in a database on 
the server. The examiner clearly also relied on the unstated assumption that the difference 
between pre-stored funds in a database and electronic money stored in a module is 
insignificant which is misguided as the difference here also reflected the significant 
structural difference between our claim (using a database) as a whole and Rosen's 

20 teaching (using modules). 



Rosen has no teaching of identifiers in view of anonvmHv . 

25 

There is no teaching of identifiers in Rosen and as per Fig 36 teaching, Rosen merely 
mention the name of the parties being paid ie Bob and Alice. In our claim, the 
Payee/Payer has an account identifier wherein linked to money accounts are ascribed in a 
database whereby the account with the pre- stored funds is stored in a host server 
30 (intermediary). More importantly there is a process to establish these account identifiers 
by users hence preserving the anonymity requirements as in real cash. 

In Rosen, the money modules are embedded in respective subscriber's devices (See Fig 
3) and are personal to each subscriber allowing only the said subscriber access by login 

35 protocol. The actual transfer is done by the transaction module which is a sub component 
of the money module. These modules are identified by the network destination number 
and not an user identifier of ones own choosing a s per our specification. ( see Claim 3 
. . .otherwise will ask the user to set up an account as an alternative option; " ). Note: 
claim 3 is now cancelled and has been rephrased as Claim 14 as" if there is no account 

40 identifier associated with said code then prompt user to enter an user account identifier, 
password, storage period and currency to be stored " 
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Rosen taught the subscriber's module identity 'as a serial number' to be one fixed/linked 
in the module by issuing bank or module provider and its never changed ( Col 12 line BO- 
SS) and as an example, Rosen pointed to applying this serial number in the form of a 
subnetwork as identifiable by the local network 16,17,18. ( Col 18 Lines 11-19). In short, 

5 this identifier is not chosen by the user but allocated by the service provider (bank) under 
its various network protocol similar to IP addresses ( 60. 1 11 . 1 1 . 1). Given an IP address is 
usually by assignment by system admin, one skilled in the art of network protocol would 
not be able to see this identifier could be a name or a number of choice as per our claim. 
While a domain name server (DNS) could theoretically be installed to map to a domain 

10 name, it is not well known to do so for a user to user payment system. And further, it still 
does not structurally meet our claim where such identifier cum password are stored in a 
database and not in a module being networked to the system. 

15 Rosen's money is a mere representation claimable on deposits Vs Stored Funds 



As mentioned in Rosen, its transfer method is only for electronic money (economic 
representation such as bank notes ) being backed by credit or claims on deposits and the 

20 real money is settled by way of tnter-bank clearing and settling. ( Col 4, line 15-19) In 
our claim 13, the stored funds are credit/debit instantly because they are already stored 
and are not claims to an external account or credit line. Being a book entry, there is no 
dependence on the primary clearing method in the banking system. Although the 
examiner did not explain this point, we are doubtful Rosen's settlement is instantaneous 

25 given the need to utilize inter-bank clearing later of claimable deposits as taught. We 
should also remember 'funds' are transferred physically from one module to another by 
moving the tokens-electronic notes by Pay/Exchange application 35 ( See Col 1 1 lines' 
66 to Col 12 lines 5 ) rather than by book entry as in our claim. 

30 Another issue is that Rosen claim that other "electronic money" by others disclosed in his 
specification are issued without the backing of equal valued liabilities as the counterpart 
to their assets. ( Col 2, lines 27 - 30 ). This clearly shows his invention is dependent on 
"backing" rather than as in ours prepaid funds which are already paid to service provider 
operating the host server, 

35 

Therefore, in conclusion, we submit thai the elements " stored funds in database, payer's 
control, account identifier, instantly crediting and debiting respective account holders in 
database" have not been meet. In addition, the examiner's assertion that fully automation 
inherently shows "without interacting with payee" is contrary to the teachings of Rosen 
40 and without factual/scientific evidence to show how a single module could make payment 
without interacting with another as per Rosen to reach our claim under the payer's 
control. Lastly although not mentioned specifically but read together with our 
specification as one must as our specification gives meaning to our terms, our stored 
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funds effected through a storage formula (not found in Rosen) are derived from pre-paid 
cards which are not found in Rosen and in fact Rosen teach against using such system at 
Col 2 line 18 which means structurally both inventions are significantly different. 

5 

Accordingly, we respectfully ask the examiner to allow these claims. 



10 



As per Claims 1 5 J9. 24 



15 



This is a 102(b) rejection. 

We respectfully transverse this rejection. 

We have grouped all claims 15, 19,24 as they have the same elements except for different 
classes where Claim 15 is the representative. 



The examiner stated Rosen: All citations from Claim 13 and Fig 7, associated text; C 10 
20 L 25-C 17 L 25; C 1 7, L28-C 18, L 67) as evidence to show anticipation. 

In view of the evidence the differences between Rosen and our Invention can be shown 
graphically below citing Table A 

25 Table A 



FIG A 



Merchant 
module 
Step 2 



ser / purchaser 
module 
step 1 



z 



TIQB 



Host Server 
Step 3 



Merchant Server 
step 1, generating 
codes spilt in two 
jharves. 




Fig A -Rosen ( See Fig 36 Steps) 


Fig B - Our Clai m 15 


Step 1- User Sign on to Transaction 


Step 1- Merchant provides 2 hakes of a 
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Module 


dynamic codes to User (x) and Host Server 
(y>. 


Step 2- Merchant Sign on to Transaction 
Module 


Step 2- User receives second code (x) from 
Merchant. Host Server receives first code 

(y)- 


Step 3- Establish session 


Step 3 - Host ask for User's codes (x) and 
Security code (z) from card. 


Step 4- Payment. 


Step 4 — Authentication of x,y,z. 



As an initial matter, we disagree with the examiner that substantial evidence supports the 
finding that Rosen contain all the limitations set forth in claim 15 which is the 
representative here. 

5 

Starting from the preamble itself, "convertible prepaid card" and in "any currencies** are 
not disclosed by Rosen Rosen did mention "Current EFT systems, credit cards, or debit 
cards, which are used with an on-line system to transfer money between accounts, such as 
between the account of a merchant and that of a customer, cannot satisfy the need for an 

10 automated transaction system that provides for the transfer of universally accepted 

economic value outside of the banking system. " ( Col 1 at line 65 - Col 2 line 4) but this 
statement merely teach against credit/debit cards or one with convertibility features. 
While Rosen further mentioned stored value cards ( Col 2 Line 16 - line 24) there is still 
no teaching of one which is convertible and in fact the context in the above lines again 

15 reflected negativing the use of prepaid cards. 

Rosen shows any currencies are asserted by the examiner but on closer reading Rosen 
actually taught of foreign currency exchange between two users. While this means in any 
currency, the reasons for doing so are different where our claim refers to paying a 

20 merchant including a merchant server, Rosen taught user to user foreign exchange 

method at Fig 46 of Rosen in line with a normal banking transaction where currency are 
exchanged but a bank is not a merchant. A bank does not sell goods in different currency 
and ask the client to convert for this purpose. Also See Col 8 lino 15 to line 24, and in 
part "... .may be used to exchange foreign currency ot make payment with another 

25 transaction money module . . . However this is a function found in a module whereas our 
claim is where the convertibility function is done by host server. The words "convertible 
prepaid card" which is used means the conversion is done by host server and obviously 
not the card which is a mere paper or plastic without any of the technological 
embodiments. As we mentioned, it would not be inherent to find Rosen's module in a 

30 paper or plastic card. 
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Referring to the body of the claim, we submit thai the steps executable at merchant 
server below are not meet by Rosen. In particular, Rosen uses a merchant point of sale 
with the embedded transaction money module for off-line transaction. 

5 "generating a first dynamic transaction code to the host server 77 

Assuming a merchant server is a point of sale terminal in Rosen embedded with 
transaction module 4, however, there is nothing to show it generating a first dynamic 
transaction code to host server. As Rosen mentioned his invention is about module to 

10 module without intermediary ( host server). Rosen* s merchant module waits for payer 
module to initiate a signon and thereof response. ( See Fig 36 of Rosen and Table A 
above). Even if one considers the 'electronic notes' 1 1 are dynamic transaction code > this 
means the merchant server (or module) is sending funds to a buyer when it should be a 
buyer sending 1 1 to merchant server. There is no evidence by the examiner to show that 

15 the seller module ( ie requesting payment ) must first send codes to the buyer in whatever 
form. As we said previously our reverse payment authentication is novel. Obviously as 
we mentioned there is no host server in Rosen and surely a host server cannot be a bank 
system which Rosen teaches against. 

20 The evidence by examiner : "It should be noted that a subscriber will not be required to 
maintain a bank account in order to own and use a Transaction money module 4, For 
instance, a subscriber may obtain a stand-alone computing device that contains a 
Transaction money module 4 and use the device only in off-line peer-to-peer transactions 
with other devices containing a Transaction money module 4, such as a merchant's point- 

25 of-sale terminal. Of course, the merchant may then transfer the electronic money to 

another commercial organization to meet its obligations, or it may deposit the electronic 
money at its own bank. " at Co! 8, Line 52-62 . (Note there is no other mention of 
merchant in the entire patent specification except for the above paragraph. ) 

30 The payment process is similar as described in Fig 36 which does not involved sending of 
codes or even codes to host server. The evidence here is quite clear and there is no need 
for us to described the routine in Fig 36-3 6A. 

"generating a second dynamic transaction code to the purchaser" 

35 

Similarly, the transaction module 4 in Rosen could not send a transaction code to 
purchaser as it requires the payer to initiate the transaction as seen in Fig 36 by signing 
on. 

40 

"at the host server having a database, receiving the first transaction code from 
merchant server" 
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As mentioned there is no identifiable host server in Rosen and hence this element is not 
anticipated. The host server could not be the bank's servers as mentioned given that once 
electronic money are issued or drawn from the deposit, the Rosen's system practically 
work without linking back to the banking system except for withdrawal and depositing of 
5 funds. This is the novelty of Rosen's invention ie a system that works outside of tire bank 
network ( EFT System). 

"requesting purchaser to provide second transaction code and security code from 
10 prepaid card" 

( Note examiner wrote payment card instead of prepaid card in page 4 of action 
letter which is not correct) 

15 A payment card could be any type of cards such as debit, credit which is linked to EFT 
system as suggested by Rosen, however a prepaid card is not be linked to the banking 
EFT system, such as telephone card. As there is no host server this element is not meet. 
Moreover, the purchaser in Rosen has no transaction codes being issued by merchant 
server ( or modules ) and certainly no prepaid card to provide the security code. It would 

20 not be inherent for a transaction module to generate a security code or first or second 
transaction code given this code is generated by merchant server. 

At col 2 line 17 to 30, Rosen wrote "The more well known techniques include magnetic 
stripe cards purchased for a given amount and from which a prepaid value can be 
25 deducted for specific purposes. Upon exhaustion of the economic value, the cards are 
thrown away. Other examples include memory cards or so called smart cards which are 
capable of repetitively storing information representing value that is likewise deducted 
for specific purposes. 

30 However, these proposed systems suffer from a failure to recognize fully the significance 
of bank deposits as money, and their necessity to back any form of universally accepted 
monetary representations that may be issued. In the systems disclosed thus far, 
representations of economic value, whether electronic or paper, are issued without the 
backing of equal valued liabilities as the counterpart to their assets.** 



35 



40 



It is clear that Rosen taught against using a prepaid card here and as such could not be 
found in his invention. 
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^receiving the second transaction code and security code a* inputted by purchaser; 
u 

This elements follows the previous one where the codes are received by the host server. 
5 Since there is no host server as per our claim, obviously this element could not be meet 
by Rosen. 

"authenticating the first transaction code and second transaction code; M 
"authenticating the said security code for validity; " 

10 

At the host server, this is followed by requesting the second transaction code and security 
code from the prepaid card which is not found in Rosen. 

We managed to solve this problem by having one static sets of code (security code) 
15 combined with a dynamic code (transaction) to be send at the same time which makes it 
harder for hackers to extract the security code ( known as chaffing ) . The examiner 
provided no evidence to show the step of combining both static and dynamic codes 
(* second code*). Further, the feet that we require the purchaser to input and send the 
second code plus prepaid card security code to host server is to ensure that a human is 
20 responding to this and not some program testing the codes. This is significant as this 

function is not one of encryption as suggested by the examiner but one of authentication. 

Our authentication method includes first combining both codes to form the base code 
satisfying that the purchase has actually confirmed the order and the order indeed 
25 originates from the merchant. For example the base merchant code could be M spilt into 
codes X and Y hence M=X+Y (as an example) where X is send to the host and Y is send 
to the purchaser and Mis a value known to the host to identify the merchant There is no 
teaching in Rosen to show such authentication method. 

30 "upon authentication of the security code, instantly crediting the amount requested 
for payment to merchant's account if the balance in said database associated with 
the security code is more than the requested amount for payment; 

instantly debiting the balance associated with the security code in said database with 
35 the said amount paid to merchant's account;" 

The steps of instantly debiting and crediting or double book entry is also not found in 
Rosen. As mentioned this is a significant step found only for prepaid cards wherein 
electronic values are already stored in the database at host server ( the intermediary ). In 
40 Rosen, all tokens of electronic notes 1 1 are stored in the transaction module ( in money 
holder 38 ) which are only uploaded when linked back to Bank's network. It is obvious 
that this is not an instantaneous debit and credit since the bank need to verify the token 
issued by another bank and accordingly debit and credit using the ACH network. While 
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Rosen taught the tokens are moved from one module to another instantaneously, this is 
not the same as showing debit and crediting, the accounting functions for centra) record 
keeping rather than storing of 'electronic money* 1 1. Each module in Rosen keeps its 
own record by Tran Log Mgr 36 ( Col 12 line 10-30) this is certainly not debit and credit. 

5 

Lastly the examiner remarked that Rosen does not recite "first transaction code and 
second transaction code are distinct" and that his teachings about encryption must 
necessarily inherently means each key or codes are distinct in order to maintain the 
highest degree of security and safety. 

10 

The requirement for anticipation requires the element to be at least inherently found in 
the prior art. Inherently means the "missing element" is well known to one skilled in the 
art to be sub stitu table or must necessarily flow from the prior art. In our case, Rosen did 
not even teach of transaction codes and while encryption which generally means 

15 encoding clear text to machine bits readable by machines is a function to hide the clear 
text using a suitable algorithm such as MD5 etc, ( Note : Rosen taught of one way hash as 
tn Col 14 line 27 to 33 ). Those skilled in the art would know that they could not be 
distinct each time if the transaction one and two are the same given the same data input. 
For example using MD5 with one way hash using "he\\o world" you will ALWAYS get 

20 the output "5eb63bbbe01eeed093cb22bb8£5acdc3*\ 

The problem here is to ask how do you ensure that "hello world" will not be created twice 
in transaction code 1 and 2 ? In other words there is no technical support to show 
whereby encryption will ensure at creation each time the transaction code 3 and 2 are 
25 distinct . The examiner provided no explanation for this. By stating it is so merely shows 
his personal judgement is being exercised rather than one skilled in the art. Obviously 
judicial notice must be provided as well. 

The second question is whether one skilled in the art would inherently recognize the 
30 notes 11 as transaction codes. Rosen has no teaching of transaction codes nor did the 
examiner explained how this element is satisfied. For this matter there is no evidence to 
show any codes such as found in Tran Log application 36 are transaction codes. ( Col 12 
lines 14-29). For example Rosen taught its electronic notes 1 1 packaged ( Col 12 lines 2- 
5). 

35 

These may be distinct as they embodied representation value and are encrypted. 
However, there is no teaching to show TWO distinct codes being sent out. Why the need 
for TWO and why must they be sent by the seller ( merchant ) instead of the buyer 
(presumably these are payment notes and not codes ). It is well known in the art that 
40 payment is done from payer to merchant and not as in our claim, merchant sending codes 
. These clearly shows the difference between notes 1 1 ( send by buyer ) in Rosen and our 
transaction codes (send by merchant ) not appreciated by the examiner. 
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The examiner unstated assumption is that because they are encrypted they must 
necessarily be distinct and hence inherently shows our transaction codes. This is 
hindsight analysis which is not proper. The examiner should be looking at any codes 
being transmitted by the modules and reason why they inherently shows our transaction 

5 codes whereby used for merchant authentication. It is also clear that Rosen uses 

encryption which may not necessarily functions like authentication as found in our claim. 
An element may be inherently disclosed by prior art if "the prior art necessarily functions 
in accordance with the limrrations" of the challenged claim. King, 801 F.2d at 1326; see 
also Standard Havens Prods., Inc. v. Gencor Indus., Inc., 953 R2d 1360, 1369 

10 (Fed.Cir,1991), cert, denied, 506 U.S. 817, 113 S.Ct. 60, 121 L.Ed.2d28 (1992). 

We respectfully ask the examiner to transverse this rejection as not all elements are found 
explicitly or inherently to show our claimed invention as a whole in particularly why the 
elements : host server receiving codes, merchant server issuing transaction codes, prepaid 
15 card's security code, transaction codes are not found. 

Similarly we respectfully submit that Claims 19 and 24 be allowed based on the 
reasoning as in Claim 15 as the only differences here is the class type of claims. 



20 



As per Claims 16. 20. 25 



25 This is a 102(b) rejection. The examiner stated Rosen: Fig 36 and 46, associated text as 
evidence to show anticipation. 

This rejection is respectfully traversed. We have grouped all claims 16,20,25 as they have 
the same elements except for different classes where Claim 16 is the representative. 

30 

As an initial matter, we disagree with the examiner that substantial evidence supports the 
finding that Rosen contains all the limitations set forth in claim 16 which is the 
representative here in particular this is a conditional dependent on the word "IF:** found 
in preamble which is missing from the examiner's analysis. Please refe r to our previous 
35 response whereby Claim 16. 25 were amended with the word 'IF' in preamble. Claim 20 
has previously am ended to include the 'IF** in the body of the claim. 

In short, if there is nothing in Rosen that test whether the currency required is foreign 
then it does not anticipated. This is not the case where as in Rosen the user wants to 
40 exchange foreign currency. This is also not the case as asserted by the examiner where 
Rosen actually teach making payment as in purchasing in foreign currency. Our claim 
relates to first detecting if foreign currency payment is required by merchant. 
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The doctrine of inherency is only applicable when the evidence makes "clear that the 
missing descriptive matter is necessarily present in the thing described in the reference, 
and it would be so recognized by persons of ordinary skill." (Continent al Can Co. USA 
v. Monsanto Co.. 948 F.2d 1264, 1268, 20 USPQ2d 1746, 1749 (Fed. Cir. 1991). 

5 

The examiner asserted " It would have been inherent for one ordinary skilled in the art to 
have included the capability for a payer to approve currency conversion rates prior to 
agreeing to a transaction, so as to make sure that no dispute would later arise as to the 
fairness of such conversion operations " 

10 

In this instance the examiner asserted the missing descriptive matter "capability to 
approve currency conversion by payer ** yyould inherently be included and provided a 
reason for it being to avoid disputes (see page 5 of action letter). 

15 Our contention here is that it is wrong to assume that one skilled in the art would 

necessarily include something whereby the something missing does not necessarily flow 
from the prior art. We submit this is the incorrect standard of anticipation under 102(b). 
"Under the principles of inherency, if the prior art necessarily functions in accordance 
with, or includes, the claimed J imitations, h anticipates." MEHL/Biophile Tnt'l Corp. v. 

20 Milgraum . 192 F.3d 1362, 1365, 52 USPQ2d 1303 t 1305 (Fed. Cir. 1999). Whether a 
claim limitation is inherent in a prior art reference is a question of fact. Schreiber. 128 
F.3d at 1477, 44 USPQ2d at 1431 . As noted, it is whether the prior art includes the 
missing element and not a proposition that one skilled in the art would include the 
missing element to reach our claim. 

25 

The pertinent point here is that Rosen has no such function to confirm converted amount 
inherently and if the examiner's suggestion calls for inclusion by one skilled in the art 
then it is clear evidence it could not anticipate, W-L- Core & Assocs, . Inc. v. Garlock. 
Inc.. 721 F.2d 1540, 1553, 220 USPQ 303, 312-13 (Fed. Cir- 1983) ("To imbue one of 

30 ordinary skill in the art with knowledge of the invention in suit, when no prior art 

reference or references of record convey or suggest that knowledge, is to fall victim to the 
insidious effect of a hindsight syndrome wherein that which only the inventor taught is 
used against its teacher."). Skill in the art does not act as a bridge over gaps in substantive 
presentation of an obviousness case, but instead supplies the primary guarantee of 

35 objectivity in the process. Ses RvkoMfg. C n v Nu-Stan Inc.. 950 F.2d 714, 718, 21 

USPQ2d 1053, 1057 (Fed.Cir. 1991). The fact that one skilled in the art would inherently 
include the feature is not substantial evidence necessarily flow from the reference. 
Furthermore, it can only confirm that because one skilled in the art has to modify first ( 
by inclusion) before reaching our claimed invention, anticipation has not been meet in the 

40 first instance. The examiner shows no evidence for this assertion and therefore the 
applicant respectfully request for such under in 37 CFR 1- 104{d)(2). 
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To rely on inherency to establish the missing features, case law in Ex parte Levy, 17 
USPQ2d 1461, 1464 (Bd. Pat, App. &. Inter. 1990) requires the examiner to provide a 
basis in fact and/or technical to support this. The mere fact that a certain thing may result 
from a given set of circumstances is not sufficient. (In re OeJrich, 666 F.2d 578,581,212 

5 USPQ 323,326 (CCPA 1 981) (quoting Hansgirg V Kemmer, 102 F.2d 212, 214, 40 
USPQ 665,667 (CCPA 1939)) (emphasis added). The examiner provided no facts or 
evidence here. Rather, the reasoning is one of desirability. However, desirability is not 
the standard for anticipation. And even if it is for obviousness, such motivation must be 
found in Rosen which evidently it is not. Anticipation requires the element to exist 

10 inherently or explicitly and not by obviousness determination. And the feet that one 
skilled has to modify only confirms that this element is not anticipated. 

Even if this is common sense, it is not well known to include this feature in light of what 
is known in the art. It is well known in the art for credit cards to be billed later at the rate 
15 determined by the credit card company or bank if the amount payable is hx a foreign 
currency. Similarly for a debit card being used to withdraw funds in different currency 
from international ATMs, hi general, we have no evidence of any system in the world 
even in 2004 that allows user to confirm the applicable exchange rate for payment 
transaction despite its fairness motivation. 

20 

This as we mentioned previously in our past responses is due to the volatility of exchange 
rate and the nature of the transaction ie a credit card for transaction which is really a 
credit payment by a bank on behalf of the user and the rate is unknown until settlement ie 
bank is paying on behalf of the purchaser first and as for a debit card, the amount is only 
25 charged upon clearing at a particular time between all the participating banks. 

Given this widely accepted practice of not allowing user to confirm or reject and with no 
noticeable complaints by credit/debit card members, how would it be obvious to show 
'fairness' as the reasoning now for prepaid cards as suggested by the examiner ? Stated 
30 differently, we could only conclude the impermissible hindsight was used. There is 

nothing in Rosen to show 'fairness' at all since both users are taking upon themselves to 
determine the rate under the bargain theory as per Fig 46. 

In Fig 46, while Rosen shows both user to user fund transfer and foreign exchange, they 
35 are taught within the context of two parties wanting to exchange one currency for another 
hence establishing the rate of exchange. In contrast, our claim is for a payment to a 
merchant using a prepaid card where if the said card's currency is not the same as 
required for payment to the merchant. Say the card is in US dollars and the merchant 
requires payment in Yen. In Rosen, the user has to initiate their respective money 
40 modules not prepaid cards or stored value in the database and it is not initiated due to a 
different currency payment requirement. 



Page 23 of 38 23 



PAGE 24/41 1 RCVD AT 7/14/2004 1 1 :45:41 PM [Eastern Daylight Time] * SVRjUSPTO-EFXRF-1/1 1 DN1S:8729326 * CSID:+1 309 4377071 1 DURATION (mnvss):17-M 



15/87/2004 14:48 +1-309-4377071 



ECQRPNU 



PAGE 



Application number 09/396005 Art Unit: 3621 

Applicant: Khai Hee Kwan Examiner David Q. Le 

Title: Method, apparatus and program to make payment in any currencies 
through a communication network system using prepaid cards 

Finally, in particular this claim is only trigger when the payment amount requested is in a 
currency other than the prepaid card's currency and the steps are taken by the host server 
and not by the users. ( See preamble "... where if said amount payable is in a currency 
other than said prepaid card's currency. . . rt ) 

5 

In short, our claimed steps are in response to the amount payable being in different 
currency and the steps are at the host server (the structural limitation). In Rosen, it taught 
user wonting/willing/desiring to exchange currency with another user ( Fig 46) using 
money modules. Given that Rosen did not teach a host server requesting purchaser to 
10 convert where the amount is in a different currency, the first step of requesting purchaser 
to convert the equivalent amount in prepaid card's currency to the requested foreign 
currency amount if the balance in the database is more than the requested equivalent 
foreign currency amount for payment ** is not met, 

1 5 Further noting that this step also need to check if the converted amount equivalent is 
greater than balance ih database before a request can be issued by host server. In short, 
this step incorporates two distinct steps first which is to detect if the currency is foreign to 
the prepaid card and secondly only when the converted amount satisfied the requested 
payment amount. 

20 

In Rosen, the steps as shown in Fig 46 shows two users establishing the exchange rate 
while in our claim step, the host server is requesting purchaser to convert further 
implying that the exchange rate is already established and this request is triggered by the 
presence of amount payable in foreign currency and not two users wishing to exchange 
25 currencies. 

As this is a request by host server, this would not meet the requirement for two users in 
Rosen which is a module to module transaction. 

30 In our claim, once purchaser has agreed the converted amount is credited for merchant 
account instantly at host server. As one can see there is no interaction with merchant on 
the rate as shown in Rosen ( assuming the merchant inherently shows second user). Our 
claim here refers to Host imeracting with the purchaser and not as in Rosen between the 
two users wishing to exchange currency. Rosen also taught exchanging currency with 

35 bank using teller module attached to bank network. However, as we mentioned, 

exchanging currency does not inherently shows detecting of the payment is in a different 
currency to trigger the exchange offering/rate subject to confirmation by payer. 

In summary, we submit that Rosen could not have meet all the limitations because Fig 46 
40 is primarily designed for Subscriber to Subscriber Foreign Exchange as titled in Fig 46. 
The teaching taught of interacting with the two subscribers while we claimed purchaser 
being requested by Host Server. The amount payable is for paying a merchant 
presumably for a service or product priced in a foreign currency. 
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Given the elements dependent from Claim 15 and are found in this claim including the 
apparent suggestion of including such function which is not necessarily found in Rosen, 
we submit anticipation under 102(b) has not been made out 

Further as Claim 16 is a dependent of Claim 3 5, our previous rebuttal is included here by 
incorporation for the missing elements of prepaid card, instantly credit and debit in 
database. 



As per claim 21 



This 102 (b) rejection is respectfully traversed. This claim refers to the elements found in 
15 the transaction code and hence dependent on claim 1 9 which we already submitted as not 
anticipated given there is no transaction code(s) being one and two as found in Rosen. 
The examiner in Claim 19 had to use "encryption* method to show that they are distinct 
which we already shown to be hindsight analysis. No evidence is provided to show why 
the receiver ( Merchant ) must necessarily issued codes in Rosen and even if it could, no 
20 reasons to show why 2 codes are send to purchaser and host server each. 

The examiner stated Rosen discloses all the limitations of Claim 21 using citations cited 
previously in Claim 13,15 and 16. 

25 Our transaction codes are used for authenticating the merchant while codes found in 
Rosen is a mere representation of electronic money 1 1 used for payment. There is no 
evidence to show such representation would inherently for authenticating the merchant ( 
payee ). The codes applied in Rosen embodies the value from the payer and bank 
signature to authenticate the issuer-bank/payer and deposit drawn being send from payer 

30 to payee while our claimed in 19 is for TWO codes to be send from payee to payer. The 
actual codes for payment ( ie security code) is provided to host server and not to the 
merchant as in Rosen. An element may be inherently disclosed by prior art if "the prior 
art necessarily functions in accordance with the limitations" of the challenged claim. 
King, 801 F.2d at 1326; see also Standard Havens Prods., Inc. v. Gencor Indus., Inc., 953 

35 F.2d 1360, 1369 (Fed. Ch\ 1991), cert, denied; 506 U.S. 817, 113 S.Ct. 60, 121 LJSd.2d28 
(1992). The examiner has not adduced any evidence to show that Rosen's codes in the 
form of Electronic Money 1 1 must necessarily function in accordance to our claimed 
limitation " transaction code " without any modification If transaction code is not found 
then alt elements in claim 21 incorporated in said code is also not anticipated. 



Wc respectfully submit that this claim be allowed. 
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As per claim 29-3 1 

5 This is a 102(b) rejection. We respectfully transverse this rejection. 

The claims here recked the "prepaid or stored value" elements which as asserted by the 
examiner to be shown in Rosen. We submit that this claim is dependent on Claim 13 
which we have already submitted not anticipated by Rosen particularly when there is no 
10 prepaid cards taught by Rosen. Our rebuttal will use 29 as the representative for 30 and 
31. 

If there is no prepaid card in Rosen could prepaid or stored value exist after activation in 
a database found in the host as described in Claim 13 ? Rosen taught of using modules 

15 where electronic money are stored as tokens 11 in a device issued by banks drawn on the 
user's deposits accounts. So the question here is whether deposit accounts in banks are 
prepaid or stored value similarly found in a prepaid card and upon storing and linking to 
account identifiers becomes a stored value ? That is to say electronic money having dual 
characteristics, one being represented in a prepaid card ( known as floating ) and the other 

20 as stored value in a database upon storing and linking as described in Claim 14 ? The 

examiner provided no specific evidence to show which aspect of Rosen's electronic note 
could be floating or stored (as mentioned our stored version includes detailed calculation 
to arrive at this value as found in Claim 26-28) 

25 As it is well known, deposit claims are actually funds belonging to the user (not bank) 
while prepaid has the meaning where funds paid to the service provider and hence not 
refundable. Both are irreconcilable and reflect different accounting treatment applying to 
different subject matter. One skilled in the art of finance would not be able to see deposits 
( belonging to user ) as now being prepaid to another for services ( money paid to service 

30 provider). How Rosen can reconcile this is unstated by the examiner. 

Therefore, we could only submit that this element has not been met. We must respectfully 
ask claims 29-3 1 to be allowed based on the reasoning above and in view of what is 
known in the art, the examiner had tailed to consider the significant difference between 
35 prepaid or stored value to Rosen's deposit/tokens (without using a prepaid card or 

existence of a database for stored value) or alternatively implied there is no difference as 
viewed by the skilled artisan even while Rosen failed to show at the minimum a prepaid 
card satisfying the prepaid or stored value features. 

40 
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As per Claims 14, 18. 23 

This is a 103(a) rejection. We respectfully transverse this rejection. 

5 

We have grouped all claims 14, 18,23 as they have the same elements except for different 
classes where Claim 14 is the representative. As we have provided above, claims 1 3., 1 7, 
22 are allowable and hence the dependent claims should also be allowed. The following 
10 response is based on the claims 1 4,1 8,23 own merits which the applicant is confident of 
being non-obvious over Rosen. 

Turning to the respective elements, the applicant disagrees that Rosen shows the 
following elements; 

15 

44 a step of storing and unking prepaid card amount to a user account identifier in 
the host server over a network comprising:" 

Firstly, Rosen did not teach of using a prepaid card and instead apply the use of claimable 
20 deposits from a bank which is downloaded to device for later transfer/payment. Account 
identifier if it exists could only be found in the device being assigned a network number 
which is not the same whereby our invention is for user to link money in a prepaid to 
their account identifier of their choice ( See our previously cancelled claim 3 detailing the 
user has the option to choose their own). Rosen taught the subscribers account identifier 
25 ('as a serial number') to be one fixed in the module by issuing bank or module provider 
and its never changed ( Col 12 line 30-33) and as an example, Rosen pointed to applying 
this serial number in the form of a subnetwork as identifiable by the local network 
16, 17,18. ( Col 18 JUnes 1 1-19). In short, this identifier is not chosen by the user but 
allocated by the service provider (bank) under its various network protocol similar to IP 
30 addresses (60.1 11. 11.1). 

"prompting user to enter security code associated with the prepaid card 1 * 

Given our steps requires user to enter security code from prepaid card, Rosen fails to 
35 show both element for prepaid card/security code and the fact that this is done by user. 
Rosen did not show user doing this step as mentioned previously. It is also unlikely that 
the Module in Rosen could inherently show a prepaid card. For instance the modules are 
said to be implemented programmatically or by direct electrical connection etc. Our 
prepaid card is a simple paper or plastic with at least a hidden security code in text 
40 without any known circuitry. Our card could not be slotted into any device or has 
electronic connections etc as found in Rosen ( Col 10 line 6-24). 

"receiving security code" 
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"determining if the security code is valid" 

Obviously both the elements here would been met by Rosen given there is no prepaid 
card or associated security code. 

5 

"Determining if any identifier account is associated with the security code;" 

Even if identifier account exists in some form as found in Rosen embedded in a device 
10 (unlike ours claim found in a database at host server) , one could not find security code as 
prepaid card was never taught in Rosen. As mentioned, previously Rosen actually teach 
the weakness of prepaid card to allude his novelty in using deposits in lieu. 



15 "If there is no account identifier associated with said code then prompt user to enter 
a unique user account identifier, password, storage period and currency to be 
stored;" 

"Determining said user account identifier and password for uniqueness against 
other stored user account identifiers and passwords;** 

20 

As mentioned, the account identifier is provided by user and not as in Rosen assigned by 
the bank. Similarly there is no password, storage period and currency. Rosens claimable 
deposits are downloaded as an electronic token signed by each bank and even if there is a 
25 storage period this would be determined by the bank and not the user, similarly the user 
would not be asked for currency to be stored as nothing in Rosen could be found to 
provide for this service and even if such service is known, it is not well known to do so 
with a prepaid card. 

30 "Calculating the stored value;" 
"Output stored value to user;" 

Our invention incorporates a unique way to store value drawn from a prepaid card as 
detailed in Claim 26. Northing in Rosen specifically deals with this and the examiner 
35 provided no explanation to show how this is obvious and/or anticipated. Even in an 
obviousness rejection, all elements must be shown to exists. 

The stored value may be different from that in the original card at activation depending 
on the currency and storage period. As shown in Stimson previously, the teaching is one 
40 of storing the exact value on activation ( Col 5 line 67 ) there is no calculating stored 
value and output calculated value. 
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Our step here means the activation or original amount initially stored in the local 
currency can be stored in accordance to the required period and currency by consent 
which is not known in the art. While it is well known in the art that prepaid services card 
comes with a predetermined period of usage, this factor however is set at the factory and 
5 not by user as per our limitation. 

Similarly, even if it would be obvious to have different currencies to be stored given the 
internationalism of trade, the applicant submits that it is not well known to do so in a 
system that links the amount to an account identifier via a prepaid card, the subject matter 

10 as a whole which is not obvious. Neither is it obvious for user to set their own period of 
storage contrary to existing art whereby set by service provider. For example with 'Value 
stored", the credit card has a limit set (exp date ) by the provider (bank) and similarly 
with debit cards or prepaid cards the amounts are determined by the user fixed at the time 
of deposit or purchase with prepaid card. Even if it is possible to do so with hindsight, 

15 this implicitly means the service provider recognized this need for user to adjust their 

stored value but given no evidence or facts or motivation from Rosen or others to support 
this, this obviousness rejection would not be sustainable. 

"if said user account identifier, password combination is unique and stored value is 
20 acceptable to user then add said account identifier and password into database 
linked with the stored value amount; and" 

"if said user account identifier, password combination is not unique and stored 
value is acceptable to user then linked the stored value amount to said existing user 
25 account identifier and password in the database." 

Similarly the above steps are not found in Rosen given each element: account identifier, 
password combination are of user own choosing so to enable the linking process to 
complete. 

30 

"whereby upon completion of storing and linking said prepaid card is valueless." 

This obviously is not meet by Rosen and others given their teachings is either to avoid 
using prepaid card or to use one where it is rechargable as in Stimson previously. Stimson 

35 taught using the prepaid card as the only means to make payment after activation and this 
would not be obvious to our need to use account identifier once the floating amount is 
stored. ( See our specification Page 10, lines 1-5). Once the amount is stored or linked to 
account identifier, the pre-paid card in our claimed invention is no longer used unlike 
Stimson 's teaching of using prepaid card for all purposes after activation (ie the reason 

40 for rechargable). In fact the card is the key with the PIN stored within. To discard the 
card would mean actually losing the money stored in database. Further as the examiner 
had never identified the element in Rosen inherently to show our prepaid card, this by 
itself would fail to meet our claim. Even if the transaction module in Rosen is our prepaid 
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card, it could not be valueless upon completion of storing and linking. Rosen depended 
on the module to make transaction and if it is valueless then Rosen's invention is not 
workable. 

5 In summary, while Rosen taught of device to device identifiers stored in money modules, 
there is no teaching of user able to link stored funds from prepaid cards to the modules or 
how this could be achieved. Rosen only teach of electronic token representation 1 ) 
having claims from deposits or credit stored in the module. No calculation of stored value 
is known which the examiner admitted at page 7 for claims 26-28 by referencing the 
10 stored value formula. In short if no formula can be found, then it is equal to admitting no 
step in calculating the stored value in Claim 14,18, 23 since the calculating step requires 
the formula. The merit of the formulation will be discussed later, 

15 The motivation/ reasons factors to sustain a 103(aV 

The examiner said that Rosen did not recite " if said user account identifier, password 
combination is not unique and stored value is acceptable to user then link the stored 
20 value amount to said existing user account identifier and password in the database; 
and (herein step 1) 

whereby upon completion of storing and Unking said prepaid card is valueless. " ( 
herein step 2) 

25 

The examiner reasoned whereby the completion of storing and liiiking, the prepaid card is 
valueless being " it would serve to thwart any possible fraudulent use of an existing 
user's account upon the pretext of adding more stored value to it and activating a new 
prepaid card," And therefore this is an obvious step inherent in a system based on Rosen. 

30 

Secondly, the examiner cited that "... .in order to provide a stronger protection element to 
the debit/stored value card system: the card user will be assured that only once properly 
activated by him/hersel£ will the account associated with the card be accessible for 
transactions. " 

35 

We submit implicitly that the said unstated differences between Rosen's modules and our 
prepaid card was not appreciated by the examiner because no evidence was presented 
inherently or explicitly to reason the differences on record. This is the third Graham 
factor: the difference between the prior art and the claims at issue, as viewed from the 
40 vantage point of one of ordinary skill in the art must be considered first and failure to do 
so would implicitly mean the graham factors were not applied consistently. A claimed 
invention is unpatentable as obvious u if the differences between the subject matter sought 
to be patented and the prior art are such that the subject matter as a whole would have 
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been obvious at the time the invention was made to a person having ordinary skill in the 
art to which said subject matter pertains " 35 U.S.C § 103(a) (1994); see Dembiczak, 175 
F.3dat998, 50USPQ2d at 1616. 

5 The money modules used by Rosen could not be obvious to a prepaid card as described in 
our specification. Rosen uses his modules fbr all purposes from login, money tn-out and 
payment. How could a paper/plastic based prepaid card with a text security code 
accomplished this 7 How could one skilled in the art see in a sophisticated money module 
as described by Rosen to reveal a simple plastic inscribed with a security code ? 

10 

And if Rosen's module does not inherently show our prepaid card then this element for 
prepaid card could not be meet and since this starting element is missing then stored 
value, calculation, password/identifier etc could not be meet. Rosen has no teaching of 
applying a prepaid card for linking and storing its funds to an account identifier/password 
15 and as mentioned its 'funds' are drawn from claimable deposits which is not found in our 
claim here. 

Valueless 

20 By suggesting that it would serve to thwart possible fraudulent use of an existing user's 
account as the motivation is too general and broad or conchisory. The question is whether 
there is any evidence in Rosen to show it is desirable to make the prepaid card valueless 
in an effort to thwart fraud. And if there is no prepaid card in Rosen ( as we asserted ) 
could its modules suggest to one skilled in the art that it should be made valueless upon 

25 storing the funds or alternatively to make the deposit account valueless ? Even when 
obviousness is based on a single prior art reference, there must be a showing of a 
suggestion or motivation to modify the teachings of that reference. See B.F. Goodrich Co. 
v. Aircraft Breaking Svs Corp.. 72 F.3d 1577, 1582, 37 USPQ2d 1314, 1318 (Fed. Cir. 
1996). 

30 

The examiner provided no evidence where or how or which element from Rosen could be 
made valueless. So we are uncertain how the motivation for thwarting illegal usage could 
be found given as we already know non of Rosen's elements ie modules, deposit accounts 
could be made valueless simply for the sake of thwarting illegal usage. 

35 

If we apply this to Rosen, this means at each download to user's transaction module, the 
deposit account would have to be valueless at the end to reach our claim. This is 
impractical unlike a prepaid card ( missing element in Rosen) as it means the user has to 
close the deposit account after each download and hence undesirable. If h is undesirable 
40 then there is no motivation regardless of thwarting fraud. 

The point here is that a deposit account could not inherently show our prepaid card nor 
can a module shows a prepaid card, this difference not appreciated by the examiner in 
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addition to their anonymity factor. The feet is that a deposit account is not a prepaid card 
which can be bought easily and conveniently for this invention purposes. Therefore 
rendering it valueless at the end will be desirable while the same cannot be said of 
Rosen's application of deposit account or modules. 

5 

If the modules are alternatively suggested to meet our prepaid card then could they be 
valueless at the completion of the linking and storing ? This also does not make sense 
given Rosen's entire teaching is dependent on the modules to store electronic funds for 
transaction after downloading the token money ? We respectfully submit that the 
10 evidences do not support step 1 and 2 to be inherently found in a system based on Rosen. 

gtrongerPrQtcctjpn . 

In short, Rosen's module (namely modules 4,5,6 in Fig 2) is already configured to 
15 creating, storing and transferring electronic notes (col 8 line 1-10) rather than linking 

stored value in a database to account identifier/password. The withdrawal process as it is 
known in Rosen is not similar or inherently shows our claim ( Col 9, line 19-24) and 
requires interacting with the teller money module 5 (bank) by transferring the electronic 
notes, not found in our claim by applying a prepaid card. As mentioned previously these 
20 modules come with identifiers that are not changeable ( Col 12, line 29-33) whereas our 
claim is for identifier of user own choosing. The question here is why would one skilled 
in the art consider modifying a sophisticated process where money tokens are signed and 
verified by a certificate authority for download to a module to one simply using an 
account identifier & password ? The examiner would need to show that our account 
25 identifier cum password would be more secure than modules. 

For a 103(a) rejection, the suggestion must be found in the prior art. See Kolmes v. World 
Fibers Corp., 107F.3d 1534, 1541,41 USPQ2d 1829, 1833 (Fed. Or. 1997) (Invention 
was not obvious where there was no suggestion or motivation to modify teaching of 
30 reference.) 

Rosen actually uses a proxy account identifier which may be "serial number " and is 
never changed ( Col 12 line 33) embodied in the money module and not as per our claim 
in the server created by user of own choosing. However, Rosen also use digital 

35 certificates and encryption in modules on presentation or transaction. Surely these are 
more secure than using account identifier cum passwords. In fact, no evidence were 
shown by the examiner to allude how Rosen's module could have weaker security as 
compare to a simple plastic with scratch-off security code or database being protected by 
user identifier of their own choice and passwords. Rosen even go as far as teaching 

40 preventing the module owner from certain access ( col 1 1 , lines 5-10) whereas in our 
invention the owner has the full authority linked to the account identifier and password. 
Obviously anyone upon picking up a prepaid card could scratch off the back to reveal the 
security code. 
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It is also debatable by substituting the prepaid card's security code for a linked account 
identifier cum password in a database would be more secure to Rosen's secured packed 
module embodied in both hardware and software. Therefore it is difficult to understand 
5 how would one skilled in the art find it desirable to adapt a lower standard while being 
motivated by the need for higher security as suggested by the examiner. There is no 
reason shown by the examiner that the modules method taught by Rosen is incapable of 
being accessible for transactions and hence obvious to associate it with a identifier and 
password to do so. 

10 

The examiner did not suggest any reasons from Rosen to show obviousness despite 
stating that it would be obvious to do so in a system Rosen and (Page 7 of action letter) 
citing only that it provides stronger protection and with the account associated with the 
card be accessible for transaction. 

15 

However, this is not found in Rosen and there is no evidence for a motivation in 
* stronger' security. Therefore we have to call for evidence under 37 CFR 1. 104(dX2) to 
show this same proposition. See also Zurko, 258 F.3d at 1386, 59 USPQ2d at 1697 
( M [T]he Board [or examiner] must point to some concrete evidence in the record in 
20 support of these findings" to satisfy the substantial evidence test). If the examiner is 
relying on personal knowledge to support the finding of what is known in the art, the 
examiner must provide an affidavit or declaration setting forth specific factual statements 
and explanation to support the finding. 

25 To rely on stronger protection as the motivation to one skilled in the art, the examiner 
would need to show that our method is well known as the desirable 'stronger' alternative 
based on account identifier linked to stored value in a database as compared to modules 
using certificates issued by Certification Agency 28 coupled with encryption for data- 
transmission and identifier set by service provider. Neither is articulated which is not the 

30 standard to show obviousness. 

If the motivation is one of security then why use account identifiers and passwords ? This 
is the weakest of all the security requirements as compared to encryption keys, 
certificates etc. Rosen already taught of using PIN, finger-print reader, voiceprint 
35 analyser, biometrics (Col 11, line 15-20), answer/question challenge ( Col 1 1, line 21-29) 
which are well known in the art to provide 'stronger' security for transactions between 
modules. This means such knowledge is well known. Rosen's method is simply to 
transfer the tokens directly from teller module to transaction module upon authentication, 
which is not found in our invention which uses an intermediary such as a host server. 

40 

Our method is to easily linked the funds from a prepaid card so to enable the user to make 
transfer or payment easily without having to remember the security code from the prepaid 
card, hence the cards are valueless once stored and linked. The same cannot be said of 
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Rosea given that the modules are retained for transactions- Neither is it taught in Stimson 
which suggested the use of the security code from the prepaid card by advocating 
recharging h. 

5 Therefore, the issue to support our claim is based creatiiog/linking account identifiers is 
and how money is eventually stored is and transfer rather than one of greater security 
which is the difference as a whole not appreciated by the examiner's analysis. 

Therefore, our conclusion is stronger protection could not be possibly be the motivation 
10 found in Rosen as there is no evidence that its protection is weak as known in the art. 

There is also no evidence to show our identifier cum password is well known in the art to 
provide stronger protection over what is known in Rosen. Furthermore there is no 
evidence to show our activation method and in particular storing of funds using a storage 
formula ( missing from Rosen ) in a database actually provides stronger protection. The 
15 examiner had used impermissible hindsight and we submit that the claims 14, IS, 23 are 
patentable over Rosen. 

We respectfully submit that these claims be allowed. 

20 

Claims 26-28 

This is a 103(a) rejection. We respectfully transverse this rejection. 

25 

Claim 26 is dependent on Claim 14 while Claims 27 and 28 are dependent on 26 and the 
difference only being the class. Therefore, we will use Claim 26 as the representative 
here. As we mentioned Claim 26 is dependent on 14 and hence incorporates all its 
limitation which we have submitted to be patentable. Claim 14 is dependent on Claim 13. 

30 

Claim 26 details calculation of stored value. 

Referring now to Claim 26*s on its own merit, the examiner asserted using personal 
knowledge that it is well known in the art that fees and/or cost for services vary on many 
35 factors etc. 

For convenience, we have restated the examiner's rejection in quotation **However it is 
well known in the art that fees and/or costs for financial services rendered by institutions 
to clients vary from institution to institution and also from client to client within each 
40 institution, depending on many factors, including the size of the institution, its business 
goals, the desirability and loyalty of the client to the institution, etc. A conversion rate 
would follow the same principles and would inherently be different from institution to 
another, and maybe for one client versus another within an institution. Therefore it would 
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have been obvious to one ordinarily skilled in the art to use a conversion formula 
structured as recited in these claims in order to reward clients for loyalty, amount of past 
business, and other positive factors and provide them incentives for continued patronage 
of each such institution." 

5 

We respectfully disagree since the examiner not only did not provide any evidence but 
stop in identifying these factors or alternatively how these factors assumed our 
formulation method. While these individual elements are old in the art, it may not be well 
known to express it as taught by our specification for storing funds linked to an account 
10 identifier (reading the claim as a whole which details a formula including multiplication 
factor and not merely the elements in the formula) as reiterated in part below. 

Stored value = B * D* L * C* R 

15 Furthermore, while it is well known that institution charges a fee, it is not well known to 
do so via a conversion formula. The examiner without stating any evidence, continued by 
stating that " A conversion rate would follow the same principles " which appears to be 
from personal knowledge. There is no evidence to show that it would follow the same 
principles and therefore we have to call for evidence under 37 CFR 1 . 104(d)(2) to show 

20 this same proposition. See also Zurko, 258 F.3d at 1386, 59 USPQ2d at 1697 ("[T3he 
Board [or examiner] must point to some concrete evidence in the record in support of 
these findings 11 to satisfy the substantial evidence test). If the examiner is relying on 
personal knowledge to support the finding of what is known in the art. the examiner must 
provide an affidavit or declaration setting forth specific factual statements and 

25 explanation to support the finding. 

The issue here is not simply because institution practices some form of fee calculation 
based on certain parameters as suggested by the examiner and fee * 'would follow" a 
conversion rate hence render our claim elements to be obvious. What is the motivation to 

30 do so in terms of a stored value when the prior art in Rosen has no such feature. There are 
many other ways to charge a fee as a percentage to payment amount in debit cards or by 
charging interest in credit cards. In foreign exchange transaction, the bank charged a 
handling fee and a percentage for small amounts. However none of them relate to prepaid 
services from a prepaid card. There is no evidence that a stored value formulation by way 

35 of a conversion has ever been used to include a fee determination. Hence the appropriate 
question is why would one skilled in the art combine a stored value formulation to 
include a fee/reward structure. The motivation must clearly be articulated from Rosen 
which inherently reveals neither. None of the elements individually are found in Rosen 
such as the face value of the prepaid card, the storage period, loyalty, flexibility of 

40 currency and cost of money. As mentioned Rosen has no prepaid card and uses a deposit 
account to download into a module without any reference to a conversion rate or one 
embedded with a fee. Loyalty which is common in many marketing schemes (in credit 
card, debit card or ATM card ) are however not found in a stored funds derived from a 
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prepaid card nor is it common for loyalty to be expressed as conversion rate to store 
funds. As we mentioned this difference between a prepaid card and others (bank related ) 
was not appreciated by the examiner. In fact, it is also pertinent to mention that each 
element is related to each other by multiplication which is not obvious. This " 
5 multiplication" relationship between said elements was not mentioned by the examiner 
and is clear not appreciated by the examiner. Even in an obviousness determination all 
the elements including a mathematical operator must be found inherently in the prior art, 
particularly when without this, the whole formula would fail. A mere conversion factor 
may not have this operator, 

10 

Then it is clear that the examiner has defined the problem in terms of its solution. In 
short, the examiner saw the solution to be 'similar* by identifying the elements and made 
that as a basis to find similar process and to conclude that it follow the principle. 
Orthopedic Equip. Co v. United States. 702 F.2d 1005, 1012, 217 USPQ 193, 199 (Fed. 
15 Cir. 1 983) ("It is wrong to use the patent in suit as a guide through the maze of prior art 
references, combining the right references in the right way so as to achieve [a desired 
result] ."). 

Furthermore, this " would follow " qualification is not the proper standard of 
20 obviousness as it implies some possibilities which might or might not follow to our 

claim. There is no scientific fact or business rule to show this qualification or authority. 
The test of obviousness is not one of probability or possibilities but one of evidence and 
facts to prevent falling into the trap of hindsight. The standard of review applied to 
findings of fact is the "substantial evidence" standard under the Administrative Procedure 
25 Act (APA). See In re Gartside, 203 F.3d 1305, 13 15, 53 USPQ2d 1769, 1775 (Fed. Cir. 
2000). 

Our formulation is targeted for calculating stored amount value for prepaid cards being 
linked to an account identifier to enable a user to user fund transfer without interacting 

30 with payee. Although fees is well known in finance art, it is not well known for a 

conversion rate that stores funds from a prepaid card linked to a combination of password 
and account identifier in view of the claim as a whole. In fact, Rosen assume that money 
stored should be equivalent to paper money derived from deposit as used. See Col 8 line 
36-39 " Naturally, it is anticipated that paper money may also be exchanged for equal 

35 valued electronic money." This is yet the clearest evidence that even if there is a fee, it is 
not done through a conversion rate. 

As noted by the court in In re Ahlert, 424 F.2d 1088, 1091, 165 USPQ 418, 420 (CCPA 
1970), the notice of facts beyond the record which may be taken by the examiner must be 
40 "capable of such instant and unquestionable demonstration as to defy dispute** (citing In 
re Knapp Monarch Co., 296 F.2d 230, 132 USPQ 6 (CCPA 1961)). In short, one skilled 
in the art must be able to identify the characterization of the formula described in our 
specification instantly as obvious from knowing fee structure in a financial institution 
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which we beg is not the case here because storing of funds derived from a prepaid card 
with an embedded fee/reward structured by applying a conversion rate is not known. 

Moving to the next issue of motivation or teaching required for an obviousness rejection. 
5 None was articulated in particular why would the skilled artisan in the financial services 
fee with knowledge of fee formulation, would be motivated to provide a * conversion rate' 
to store funds and/or reward/charge accordingly from prepaid cards customers ? 

This factual question of motivation is material to patentability, and could not be resolved 
10 on subjective belief and unknown authority. It is improper, in determining whether a 
person of ordinary skill would have been led to this, simply to "[use] that which the 
inventor taught against its teacher." W.L. Gore v. Garlock, Inc., 721 F.2d 1540, 1553, 220 
USPQ 303, 312-13 (Fed. Cir. 1983). As we mentioned this motivation was not found 
from Rosen. While it is well known to include a fee structure for a transaction in the 
15 finance art, such fee is usually based on transactions covered and not storage of funds. 
Our fee is based on storage requirement without referencing a 'transaction 5 as yet. In fact 
the customer need not store this amount and therefore need not incur a fee provided he 
use the prepaid card's security code for transaction. 

20 In conclusion "conversion rate" as described in our claimed invention within the context 
of linking said "converted amount" to a user identifier enabling user to user fund transfer 
originating from a prepaid card as per claim 14 and 13, is unknown in the art, viewing the 
claim as a whole would not be obvious. 

25 Based on the two legs of our rejection 1) unsupported personal assertion and 2) lack of 
evidence of teachings or demonstrable motivation, we respectfully call the examiner to 
allow claim 26-28. 
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Declaration 37 CFR 1.132 



5 



10 I hereby declare that all statements made herein of my own knowledge are true and that 
all statements made on information and belief are believed to be true; and further that 
these statements were made with the knowledge that willful false statements and the like 
so made are punishable by fine or imprisonment, or both, under section 1 001 of Title 1 8 
of the United States Code, and that such willful false statements may jeopardize the 

15 validity of any application, any patent issuing thereon, or any patent to which this verified 
statement is directed. 
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